Mikael Carneholm wrote:
> 
> "J. Grimbert" wrote:
> 
> > First of all, a point is a 0-dimension object...
> > I guess you would then ask for a line (straight)
> > and then some more complicated lines (bezier in a plane, total free in
> > 3d space)
> > That would give some 1-dimension object.
> > And the fractal gurus will come and ask some 1.65-dimensions fractals
> > up to the dreaded true 2-dimension plane object... (not the pov plane)
> > And then a sponge primitive
> 
> Nope. But a point is such a basic "primitive" that it's a good idea to include
> it. A sponge though, is not a very basic primitive. Or is it? As useful as a
> teapot maybe..
> 

Well, a point object does not exist. It's an abstraction for maybe an
atom.
Moreover, using the "object" term would be very misleading...
My generalisation from the point to the sponge was just to show
what may happen once you've agree to provide a point object. 
You will have trouble refusing an elementary line (also an abstraction)
and so on.

Oh, what about a klein bottle primitive ?  (just kidding)

> > Your point looks like a vector.
> > #declare POINT_IDENTIFIER = POINT_LOCATION;
> >
> 
> It sure does. But you can't union{} a bunch of declarations and affect the
> locations of the declared vectors by putting them inside a union and then
> translate/rotate the whole union.
> 

Ok, now, there is really a need here.
But the point object is not the solution.

What is needed is probably more something like array operator.
After all, pov have :
 rotate and translate for objects
 vrotate and + for vectors

We may probably get a nice enhancement with something like
 arotate and atranslate for array of vector

#declare new_array = arotate(old_array, B );

and 
#declare new_array = atranslate(old_array, B);

BTW, we could also need some scaling:
#declare new_array = ascale(old_array, B);

> > Well, you actually do not have to deal with math,
> > you have to read the manual :-)
> > (and that's something hard! the manual is quiet big to remember
> > everything )
> 
> I can assure you I'm not the type of guy that doesn't read the docs. And I
> don't think the purpose of the manual is to memorize the whole thing, I belive
> most users (me included) just use it to check some syntax once in a while -
> but only when necessary.

Well, I believe you read the manual (vrotate is not self evident).
But I have even problem just to remember all the possibilities from the
various sections:
 object, pattern, vectors, light, camera and so on.

Some months ago, there was a challenge about giving 'from head' all the
available patterns.
It was very difficult!

> 
> >
> > Why a vector array in your case ?
> 
> Because it's more convenient.
> 
> >
> > I sincerely does not feel the need for an object that you cannot see...
> > and the vector is already present.
> 
> Argument: You reduce the amount of code necessary to do certain operations.
> Let's say you have a spaceship with some lightsources on which you want to use
> some lens flare effect; due to the "limitation" today, you have to have
> separtate declarations for each vector and it's translation. If there was a
> point primitive, you could declare MySpaceShip=union{ImportedMesh + some
> points} and then translate it as a unit - which is much more natural, as
> that's how we percieve an object when we see it even if it's a complex object.
> 

Well, I would rather have a set of array functions than misusing the
union.
You will still have to duplicate the transformation (once for the
objects,
and once for the array), but that would be better than now.
(and adding vectors to the array would not request any new duplication)

Now, I cannot believe that I now agree that there is something missing
in pov. Or is is already somewhere in the manual ?

Post a reply to this message